Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-132

Text File | 1996-01-18 | 54.3 KB | 1,562 lines | [TEXT/R*ch]

C.S.M.P. Digest             Thu, 18 Jan 96       Volume 3 : Issue 132

Today's Topics:

        FYI: Web page with info on devloping MacOS Lotus Notes apps
        How do I do ZoomRects?
        How do I make finder show new contents of folder?
        How to get default user name
        Monitor Numbering
        Restoring the Color Environment
        Sprite Collision detection
        char *pixel access; SwapMMUmode?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Rick Gansler)
Subject: FYI: Web page with info on devloping MacOS Lotus Notes apps
Date: Wed, 03 Jan 1996 16:35:52 -0500
Organization: Boardwalk Software

I just posted a page with about 40k of text about the Lotus Notes C API,
from the perspective of a Mac developer.

Please feel free to browse it and distribute the link.

http://www.tiac.net/users/gansler/notes/notes.html

--
                                                  ___
Rick Gansler, Boardwalk Software                 |   \
Mac & Windows Software Development & Consulting  |___/o a r d w a l k
[e-mail]                   ====|===\=================
http://www.tiac.net/users/gansler/               |___/   software

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: How do I do ZoomRects?
Date: Tue, 2 Jan 1996 20:38:10 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

How do I implement a ZoomRect (a thin gray rectangle that "zooms out" when
a window opens or closes, as when you open one of the Finder's directory
windows)?  Is there a built-in Toolbox trap to do this already?

-Tim DeBenedictis
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Lawrence Kearney)
Date: Tue, 02 Jan 1996 14:53:36 -0700
Organization: Applied Signal Technology

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

> How do I implement a ZoomRect (a thin gray rectangle that "zooms out" when
> a window opens or closes, as when you open one of the Finder's directory
> windows)?  Is there a built-in Toolbox trap to do this already?

Try looking in the book Macintosh Programming Secrets.  I found a copy of
all the source code in the book on the net somewhere but I don't remember
exactly where. It was in the file "MPS disk V1.0.1". The code can be found
in chapter 7.

--
Larry Kearney                   |   "You want fries with that?"
Applied Signal Technology       |
[e-mail]        |

+++++++++++++++++++++++++++

>From David Reiss <[e-mail]>
Date: 3 Jan 1996 02:10:47 GMT
Organization: http://www.astro.washington.edu

Also, look into the drag manager.  There's a nice little trap, ZoomRects,
I think it's called.  It does just this.  But you need the Drag Manager
for it to work.

There's also sample code for this on Apple's web server.

-David


+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Wed, 3 Jan 1996 02:16:21 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Lawrence Kearney ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (Tim
: DeBenedictis) wrote:

: > How do I implement a ZoomRect (a thin gray rectangle that "zooms out" when
: > a window opens or closes, as when you open one of the Finder's directory
: > windows)?  Is there a built-in Toolbox trap to do this already?

Also, get "MyCard" and/or "MyNewCard" off ftp AmbrosiaSW.com
/pub/alt.sources.mac/alt.sources.mac

About volume6 or 7 (?).  There's an index there, too.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Erichsen)
Date: Tue, 02 Jan 1996 23:47:04 -0800
Organization: Disorganized

In article <[e-mail]>,
[e-mail] (Lawrence Kearney) wrote:

> How do I implement a ZoomRect (a thin gray rectangle that "zooms out" when
> a window opens or closes, as when you open one of the Finder's directory
> windows)?  Is there a built-in Toolbox trap to do this already?

If you've got the Drag Manager installed, there's two routines, ZoomRects
and ZoomRegion that do just what you want. If you want to know how to do
it, read Mac Programming Secrets as someone else already suggested.

---------------------------

>From [e-mail] (Tor Langballe)
Subject: How do I make finder show new contents of folder?
Date: 28 Dec 1995 18:12:44 GMT
Organization: Cutting Edge

My application copies files to a folder and changes files names.
Unfortunatly the changes aren't immediatly visible in the finder, I have
to close, then open the folder to see the changer. How can I force this to
happen?

I've tried changing the folders modification date with the following code,
but it didn't help:

bool ForceFinderToUpdateFileIcon(const char *filename)
{
  long       dirID;
  short      volref;
  CInfoPBRec tempPB;

  if(GetDirectoryID(filename, &dirID, &volref)) // (from full path)
  {
    tempPB.dirInfo.ioNamePtr = 0L;
    tempPB.dirInfo.ioVRefNum = volref;
    tempPB.dirInfo.ioFDirIndex = -1;
    tempPB.dirInfo.ioDrDirID = dirID;

    if(PBGetCatInfoSync(&tempPB) == noErr)
    {
      tempPB.dirInfo.ioDrMdDat = LMGetTime();
      tempPB.dirInfo.ioDrDirID = dirID;
      return PBSetCatInfoSync(&tempPB) == noErr;
    }
  }

  return FALSE;
}

thanks,

Tor Langballe

Tor Langballe
Cutting Edge Technologies
Norway

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 29 Dec 1995 01:17:17 -0500
Organization: America Online, Inc. (1-800-827-6364)

Tor Langballe wrote:
>My application copies files to a folder and changes files names.
>Unfortunatly the changes aren't immediatly visible in the
>finder, I have to close, then open the folder to see the
>changer. How can I force this to happen?

The most reliable way to force the Finder to notice your changes is to
tell it to "update" using the scriptable Finder. You can find code that
shows how to do that with the article "Scripting the Finder From Your
Application" by Greg Anderson in develop magazine issue #20 (probably
available at
ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Periodicals
/develop/develop20/ if I were to guess the URL).

If the scriptable Finder isn't available (check with Gestalt, the
gestaltFinderAttr selecter, looking at the gestaltOSLCompliantFinder bit),
then you can use BumpDate or FSpBumpDate from the MoreFiles sample code to
touch the modification date of the file's parent directory. Touching a
directory's modification date will make the Finder notice your changes
most, but not all, of the time.

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Fri, 29 Dec 1995 17:11:58 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Tor Langballe ([e-mail]) wrote:
: My application copies files to a folder and changes files names.
: Unfortunatly the changes aren't immediatly visible in the finder, I have
: to close, then open the folder to see the changer. How can I force this to
: happen?

get "ctc 1.6" and look at the "tickle" routine.  As I recall, it's for
the purpose of making the Finder take notice of changes in its turf.

-Ken-

+++++++++++++++++++++++++++

>From Jeff Pritchard <[e-mail]>
Date: Wed, 03 Jan 1996 19:11:18 -0700
Organization: NSI/INOW

Tor Langballe wrote:
>
> My application copies files to a folder and changes files names.
> Unfortunatly the changes aren't immediatly visible in the finder, I have
> to close, then open the folder to see the changer. How can I force this to
> happen?
>
> I've tried changing the folders modification date with the following code,
> but it didn't help:


This is a tricky one in some cases.  If all you are doing is what you say above,
then sending an update event to the Finder should do what you need. Try something
like this (the fsspec has the parent dir ID of the directory you changed and the
name of the dir you changed):

void SendUpdateAppleEvent(FSSpec *directory)
        {
        AppleEvent                              the_apple_event;
        AEAddressDesc                   target_address;
        AppleEvent                              theAEReply = {typeChar, nil};
        AESendMode                              theSendMode = kAENoReply;
        OSErr                                   error;
        ProcessSerialNumber     tempPSN;
        OSErr                                   myErr = noErr;
        ProcessInfoRec                  infoRecToFill;
        OSType                                  typeToFind = 'FNDR';            // the finders type and creator
        OSType                                  creatorToFind = 'MACS';
        unsigned char                   name[32];
        FSSpec                                  spec;

        tempPSN.lowLongOfPSN = kNoProcess;
        tempPSN.highLongOfPSN = kNoProcess;
        infoRecToFill.processInfoLength = sizeof(ProcessInfoRec);
        infoRecToFill.processName = name;
        infoRecToFill.processAppSpec = &spec;

        do      {
                myErr =  GetNextProcess(&tempPSN);

                if(myErr == noErr)
                        GetProcessInformation(&tempPSN,&infoRecToFill);

                } while(((infoRecToFill.processSignature != creatorToFind) ||
                         (infoRecToFill.processType != typeToFind) ) &&  (myErr == noErr));

        if(myErr != noErr)
                return;                         // abject failure, give up in disgust

        error = AECreateDesc(typeProcessSerialNumber, &tempPSN,
                                                sizeof(ProcessSerialNumber), &target_address);

        if(!error)
                {

                error = AECreateAppleEvent('fndr', 'fupd',
                                                                                &target_address,
                                                                                kAutoGenerateReturnID,
                                                                                kAnyTransactionID,
                                                                                &the_apple_event);

                if(!error)
                        {
                        error =
AEPutParamPtr(&the_apple_event,keyDirectObject,typeFSS,directory,sizeof(FSSpec));

                        if(!error)
                                {

                                error = AESend(&the_apple_event, &theAEReply, theSendMode,
                                                                kAENormalPriority, kAEDefaultTimeout, nil, nil);

                                AEDisposeDesc(&the_apple_event);
                                AEDisposeDesc(&theAEReply);
                                }
                        }

                AEDisposeDesc(&target_address);
                }

        }


In my case, I was changing some other things that the Finder wouldn't update with
this simple approach.  In particular, I was changing a file from a real file to an
alias file with the same name.  The only way I have found that works is really
weird!  You have to move the file to the trash (programatically), and then send a
"putaway" command to the Finder.  This puts the file back where it belongs, and
does update EVERYTHING   about the file in the process.  Hopefully you won't have
to go to these extremes!

+++++++++++++++++++++++++++

>From [e-mail] (Jim Friedlander)
Date: Wed, 03 Jan 1996 21:02:07 -0800
Organization: Interaxus

In article <[e-mail]>, [e-mail] wrote:

> Tor Langballe wrote:
> >
> > My application copies files to a folder and changes files names.
> > Unfortunatly the changes aren't immediatly visible in the finder, I have
> > to close, then open the folder to see the changer. How can I force this to
> > happen?
> >
> > I've tried changing the folders modification date with the following code,
> > but it didn't help:
>
>
> This is a tricky one in some cases.  If all you are doing is what you
say above,
> then sending an update event to the Finder should do what you need. Try
something
> like this (the fsspec has the parent dir ID of the directory you changed
and the
<<<<snip>>>>>

or, you can use the following routine to simply change the modification
date of the folder the file is in...it works for me :)

jim


/*
   This routine is used to force the Finder (as much as is possible) to update
   information about a newly changed file or folder.
   It does this by changing the modification date of the surrounding folder.
*/
OSErr ForceFinderUpdate(FSSpec *pFSS, Boolean flush)
{
   OSErr       lErr;
   CInfoPBRec     lCBlk;

   if (pFSS->parID != 1)   // if it's a vol then reuse the NameStr
      lCBlk.dirInfo.ioNamePtr = 0L;
   lCBlk.dirInfo.ioVRefNum = pFSS->vRefNum;
   lCBlk.dirInfo.ioDrDirID = pFSS->parID;
   lCBlk.dirInfo.ioFDirIndex = 0;
   lCBlk.dirInfo.ioCompletion = 0;

   lErr = PBGetCatInfoSync(&lCBlk);
   if (!lErr) {
      GetDateTime(&lCBlk.dirInfo.ioDrMdDat);
      lCBlk.dirInfo.ioDrDirID = pFSS->parID;
      lErr = PBSetCatInfoSync(&lCBlk);

      if ((!lErr) && (flush))
         lErr = FlushVol(nil, pFSS->vRefNum);
   }

   return (lErr);
}

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|              Jim Friedlander   *   [e-mail]            |
|                     <http://www.interaxus.com>                  |
|                                                                 |
|           A hamburger by any other name is more expensive       |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

---------------------------

>From [e-mail] (Haseen I. Alam)
Subject: How to get default user name
Date: 29 Dec 1995 06:41:06 GMT
Organization: University of Minnesota


 Hello:

 I am trying to write a small external routine in C to get the default user
 name set in the Sharing Control Panel.  I tried the function GetDefaultUser
 using the following code fragmant in Symentec C++, but I get the following
 result Error# -923, Ref# 28012900, Name: , According to Think Reference,
 -923 is noLoggedInErr, meaning Default user reference number does not 'yet'
 exist.  I do have my name in the owner name field.  I am clueless!

 I would greatly apprecite any help with this issue.  Thanks in advance.
 (PS: please e-mail your responses.)

 -- Haseen


    #include <stdio.h>
    #include <stdlib.h>
    #include <PPCToolbox.h>
    #include <Types.h>

    int main()
    {
        int iErr;
        unsigned long * userRef;
        Str32 userName;
        iErr = GetDefaultUser(userRef,userName);
        printf("Error# %d, Ref# %d, Name: %s,\n",iErr, userRef,userName);
        return EXIT_SUCCESS;
    }

 .------------------------------------------------------------------------.
 | Haseen I. Alam   [phone]  | "If you think I am expensive, wait  |
 | email: [e-mail]           |     till you hire an amateur!"      |
 `------------------------------------------------------------------------'

+++++++++++++++++++++++++++

>From [e-mail] (Malcolm H. Teas)
Date: 29 Dec 1995 15:25:21 GMT
Organization: Blaze Technology, Inc.

There's a system string resource with the ID of -167xx. (Don't remember
the last few digits.)  This holds the name of the owner of the Mac.
This name is set in the Owner Name field in the Sharing Setup control
panel.

Malcolm  H. Teas                E-Mail: [e-mail]
Blaze Technology, Inc.          Telephone: [phone]
PO Box 200279                   Fax: [phone]
Austin, TX USA 78720-0279
   ** A Macintosh software development services company  **

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 30 Dec 1995 15:43:10 -0500
Organization: America Online, Inc. (1-800-827-6364)

Haseen I. Alam wrote:
>I am trying to write a small external routine in C to get the
>default user name set in the Sharing Control Panel.  I tried the
>function GetDefaultUser using the following code fragmant in
>Symentec C++, but I get the following result Error# -923, Ref#
>28012900, Name: , According to Think Reference, -923 is
>noLoggedInErr, meaning Default user reference number does not
>'yet' exist.  I do have my name in the owner name field.  I am
>clueless!

GetDefaultUser is a PPC Toolbox routine that returns the default PPC user
reference number and user name *after* the user has used the name and
password entered in the Sharing Setup control panel to authenticate
themselves to a remote system. Until the user has done that,
GetDefaultUser will return noLoggedInErr (-923).

What you really want to do is use GetString to get a handle to 'STR '
resource -16096 like this:

StringHandle userNameHandle;
Str255       userName;
/* Get the user name and make a copy of it. */
/* Don't release or dispose of the system resource handle. */
userNameHandle = GetString(-16096);
BlockMove(*userNameHandle, &userName, *userNameHandle[0]+1);

- Jim Luther

---------------------------

>From [e-mail] (Jon Pugh)
Subject: Monitor Numbering
Date: Sat, 30 Dec 1995 18:57:27 GMT
Organization: Will hack for food

I'm making my screen list scripting addition return an index for the monitors
and I would like it to match the numbers that the Monitors cdev puts up
when you press Identify.  My first attempt, which numbered them from the
first GDevice in the list and up, turned out wrong, but given that I only
have two monitors, I don't have a nearly big enough sample to determine if
it's simply the reverse of that or what.  Does anyone know how the cdev
numbers them?  I suppose it's into the code editor to see how it's done if
no one knows.  ;)

Also, does anyone remember the name of the routine which changes the
resolution? I think it's in QuickTime 2.1, but didn't see it on a fast
look at the includes included.

Jon


+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 30 Dec 1995 23:14:43 GMT
Organization: University of Michigan

Jon Pugh, [e-mail] writes:
> Also, does anyone remember the name of the routine which changes the
> resolution? I think it's in QuickTime 2.1, but didn't see it on a fast
> look at the includes included.

I found such information in the Display Manager SDK, which is typically
found at the following URL (however, it seems to be down over the holiday
weekedn).

   <ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/
        System_Software_Extensions/Display_Manager_Development_Kit/
        Display_Manager_Developmen.sit.hqx>

Matt

* * * * * * * * * * * * * * * * * * * * * * * * * * ======================
*  Reality: Matt Slot                             *  Time is an illusion.
*  E-Mail:  mailto:[e-mail]             *  Lunchtime doubly so.
*  Web:     http://www.sils.umich.edu/~fprefect/  *     -- Douglas Adams
* * * * * * * * * * * * * * * * * * * * * * * * * * ======================

+++++++++++++++++++++++++++

>From [e-mail] (JovianSoft)
Date: 31 Dec 1995 07:12:28 -0500
Organization: America Online, Inc. (1-800-827-6364)

>Also, does anyone remember the name of the routine which changes the
>resolution? I think it's in QuickTime 2.1, but didn't see it on a fast
>look at the includes included.

Volume VI of Inside Mac has the following routines to get depth info &
change it:

HasDepth()
SetDepth()

It's in the Graphics Device Manager section.

Hope this helps (HTH)


+++++++++++++++++++++++++++

>From [e-mail] (John W. Blackburne)
Date: 01 Jan 1996 06:58:03 GMT
Organization: Tempest, Hong Kong

Jon Pugh,[e-mail], wrote:
> I'm making my screen list scripting addition return an index for the
monitors
> and I would like it to match the numbers that the Monitors cdev puts up
> when you press Identify.  My first attempt, which numbered them from the
> first GDevice in the list and up, turned out wrong, but given that I only
> have two monitors, I don't have a nearly big enough sample to determine if
> it's simply the reverse of that or what.  Does anyone know how the cdev
> numbers them?  I suppose it's into the code editor to see how it's done if
> no one knows.  ;)

I think it's a hardware ordering, sensed at startup or wake up. I don't
really have much evidence to support this, as I'm only going by the way my
6100av works, but I also remember that many Macs can check NuBus slot
ordering for video devices, even if the Mac doesn't have NuBus slots: E.g. I
remember the 165c's internal and external video had a virtual NuBus slot for
each device. The 'scrn' resource (documented in IM V) has slot numbering info
for devices.

This may not work on PowerMacs, as they all require the Display Manager,
which replaces the old Slot Manager way of doing things. In particular the
latest Macs with PCI probably have no need for NuBus emulation. But I'm
mostly guessing here - apart from the Display Manager SDK docs this is all
very poorly documented, and there's nothing anywhere on Monitor CDEV device
numberings.

I looked at this for my screennmode OSAX, but the only way I could see to do
it was by walking the display list using GetMainDevice and GetNextDevice and
using this as an ordering. This is OK for two displays but the order is
unpredictable for more, and changes if the user changes main device at any
time. Another way would be to use their locations to number them from left to
right, but this fails with some display arrangements and again changes as the
user moves things around.

> Also, does anyone remember the name of the routine which changes the
> resolution? I think it's in QuickTime 2.1, but didn't see it on a fast
> look at the includes included.

AFAIK the only way documented and only way compatible with the latest
machines is through the Display Manager API.

John
--
John Blackburne:        [e-mail], [e-mail]
Programmer, Asia, Inc. Online:       http://www.asia-inc.com
Consultant, trainer & writer: http://www.hk.super.net/~johnb

---------------------------

>From Paul Czarnecki <[e-mail]>
Subject: Restoring the Color Environment
Date: Tue, 2 Jan 1996 03:51:42 GMT
Organization: Customline Software

I am writing a program which displays images with custom
palettes.  I am using the palette manager, CW7.

When I close my window, the default palette isn't restored.
I am making this call

SetPalette((WindowPtr) aWin, nil, true);
ActivatePalette((WindowPtr) aWin);

before I close my window.  But nothing happens.

Now IM is a little unclear here, I don't know if you are
allowed to pass nil to SetPalette.  Is is ok?

I guess I could get the default system ones, but which one I
choose?  The deepest monitor?  The one the window I am
closing is on?  The menu bar one?  What should I do if I
span monitors?

Thanks!

pZ
--
Paul Czarnecki -- Customline Software
Macintosh Contract Programming -- Imaging -- Internet
MacApp -- PowerPlant -- C/C++ -- HTML
[e-mail] -- http://www.artsys.com/ner

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Tue,  2 Jan 1996 12:13:54 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

Paul Czarnecki <[e-mail]> writes:
> I am writing a program which displays images with custom
> palettes.  I am using the palette manager, CW7.
>
> When I close my window, the default palette isn't restored.
>
> I guess I could get the default system ones, but which one I
> choose?  The deepest monitor?  The one the window I am
> closing is on?  The menu bar one?  What should I do if I
> span monitors?

If you'll look at your Palette Manager chapter of NIM: Color Imaging
(I don't know if that's out on dead trees, but it's on FTP and develop
CDs)...

RestoreDeviceClut (GDHandle gdh);

will return the given monitor to its default colors. You can probably
use DeviceLoop or something to go through and do this to each monitor
that your window touches.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From Paul Czarnecki <[e-mail]>
Date: Wed, 3 Jan 1996 03:51:32 GMT
Organization: Customline Software

>When I close my window, the default palette isn't restored.
>I am making this call
>
>SetPalette((WindowPtr) aWin, nil, true);
>ActivatePalette((WindowPtr) aWin);
>
>before I close my window.  But nothing happens.
>
>Now IM is a little unclear here, I don't know if you are
>allowed to pass nil to SetPalette.  Is is ok?

Doing this works.

        RestoreDeviceClut(nil);
        SetPalette((WindowPtr) mMacWindowP, nil, true);
        ActivatePalette((WindowPtr) mMacWindowP);

It's curious, that doing just this:

        RestoreDeviceClut(nil);

or just these:

        RestoreDeviceClut(nil);
        ActivatePalette((WindowPtr) mMacWindowP);

do not work.  In both cases, the palette is sucessfully
restored (I had the Monitors Control Panel to watch my
palette) but Finder's window's were still messed up.  In the
first case, the colors didn't change at all, in the 2nd
case, they changed, but to an odd set, even though the
palette was correct.  Making all three calls is the
solution.

pZ
--
Paul Czarnecki -- Customline Software
Macintosh Contract Programming -- Imaging -- Internet
MacApp -- PowerPlant -- C/C++ -- HTML
[e-mail] -- http://www.artsys.com/ner

---------------------------

>From [e-mail] (Emmanuel Rayzal)
Subject: Sprite Collision detection
Date: Wed, 13 Dec 1995 18:14:25 +0200
Organization: Internet-Way

For my first game, I'm using encoded sprites as described in Chapter 3
"Advanced Graphics" of Tricks of the Mac Game Programming Gurus.

I need pixel level collision detection, but I don't see any simple and
elegant way to do this with encoded sprites. I wonder if I shouldn't
generate bitmaped masks just for collision detection.



Any suggestions ?

Emmanuel

+++++++++++++++++++++++++++

>From [e-mail] (Mark Elliott)
Date: 14 Dec 1995 08:53:52 GMT
Organization: Max-Planck-Institut f. Kohlenforsch. Muelheim

In article <[e-mail]>,
[e-mail] (Emmanuel Rayzal) wrote:

> For my first game, I'm using encoded sprites as described in Chapter 3
> "Advanced Graphics" of Tricks of the Mac Game Programming Gurus.
>
> I need pixel level collision detection, but I don't see any simple and
> elegant way to do this with encoded sprites. I wonder if I shouldn't
> generate bitmaped masks just for collision detection.
>
>
>
> Any suggestions ?

I do not use encoded sprites, but I see no reason for this technique not
to work. What I do is first to check my sprite list for a likely collision
(i.e. the Rects of my enemy sprite and my player sprite overlap). I then
have a collision detection GWorld where I draw my enemy sprites. Next I
'draw' my player sprite, but instead of drawing the pixels I do something
like

if ((*player | *dest) != (*player & *dest)) collision = true;

(check the logic - this is just off the top of my head).

I guess this is not the fastest way, but I can't think of a faster way of
doing true pixel level collision detection. I suppose for each line of
each sprite you could have values stored for the left/right limits of the
sprite, but this would not be 100% safe if you have gaps in the middle of
your sprite.

nb. The pointers are to longs, so this method checks 4 pixels at a time. I
also make sure that I am only checking the absolute minimum number of
sprites (usually only one or two per frame).

If you need more info/specific code, let me know.

regards

Mark

- ------------------------------------------------------------------
Mark C Elliott                           [e-mail]
Max-Planck-Institut                      voice: ([phone]
Fuer Kohlenforschung
Muelheim, Germany
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Wed, 13 Dec 1995 22:11:30 -0800
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <[e-mail]>,
[e-mail] (Emmanuel Rayzal) wrote:

> For my first game, I'm using encoded sprites as described in Chapter 3
> "Advanced Graphics" of Tricks of the Mac Game Programming Gurus.
>
> I need pixel level collision detection, but I don't see any simple and
> elegant way to do this with encoded sprites. I wonder if I shouldn't
> generate bitmaped masks just for collision detection.
>
>
>
> Any suggestions ?
>
> Emmanuel

Hey there --

There are several possible approaches to collision detection:

1. Rects. This is the simplest and the fastest. Assign a rect that
approximates the size and shape of the sprite and check with these. Even
if you don't use this for final checks, checking for collisions with
bounding rects will eliminated all the trivial cases quicky.

2. Multiple rects. Instead of one rectangle, store several rects whose
union defines the shape of the sprite.

3. Circles. Store a midpoint and radius for each spite. To determine the
collision check if the distance between the two midpoints is less than the
sum of the radii. (Skip the square root -- check to see if the sqare of
the distance is less than the square of the sum of the radii).

4. Spans. Modify the encoder so that is stores a start and end point for
each scan line of the shape. Then check if these spans collide. Works
great for convex shapes w/o holes.

5. Bitmaps. Store a bitmap of each shape and check the collision this way.
It will give you the best accuaracy, but the slowest check.

For very simple shapes I would use a combination of 1,2 and 3. For complex
shapes I would use 4. I think that 5 is only needed in rare cases.

Just my thouhgts --

Mick

+++++++++++++++++++++++++++

>From [e-mail] (Gordon Henriksen)
Date: 22 Dec 1995 17:15:17 GMT
Organization: Micron Internet Services

In article <[e-mail]>,
[e-mail] (Emmanuel Rayzal) wrote:

> For my first game, I'm using encoded sprites as described in Chapter 3
> "Advanced Graphics" of Tricks of the Mac Game Programming Gurus.

> I need pixel level collision detection, but I don't see any simple and
> elegant way to do this with encoded sprites. I wonder if I shouldn't
> generate bitmaped masks just for collision detection.

> Any suggestions ?

Well, yes. I don't see an elegant way to do collision detection through
run length encoded (RLE) sprites either. RLE accelerates the drawing
process to much to give up, so, if I may, I would like to suggest that you
maintain both the RLE data AND a bitmap collision mask. This is more
flexible because, often the drawing mask does not produce desirable
results for collision detection.

There is a significant amount of information on collision detection at
<x2ftp.oulu.fi:/pub/msdos/programming/> much of it is only theory, so it
is cross platform.

                      TTFN,
                        Gordon Henriksen
                        [e-mail]

+++++++++++++++++++++++++++

>From Bernie Wieser <[e-mail]>
Date: 27 Dec 1995 22:16:32 GMT
Organization: Octavian Micro Development Inc.

On the Macintosh, you can do something which is quite simple,
but not too portable that handles pixel collision.

The basic form is this; you have a bitmap (not a pixmap) that you
can convert to a region.  Then just call
the toolbox on the regions for intersection.
This means your sprite object has a region,
but you can dispose of your bitmap once you've
got the region.

B.




+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Fri, 29 Dec 1995 00:38:53 +1000
Organization: University of Queensland

In article <4bsgk0$[e-mail]>, Bernie Wieser <[e-mail]> wrote:

> On the Macintosh, you can do something which is quite simple,
> but not too portable that handles pixel collision.
>
> The basic form is this; you have a bitmap (not a pixmap) that you
> can convert to a region.  Then just call
> the toolbox on the regions for intersection.
> This means your sprite object has a region,
> but you can dispose of your bitmap once you've
> got the region.
>
> B.

yeah, is good and simple. and slow.
way too slow for any fast-paced game (unless of course u have a faster ppc...)
good method for a slow moving game tho..

+++++++++++++++++++++++++++

>From [e-mail] (Lam Dang)
Date: Thu, 28 Dec 1995 16:28:18 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)


Yah, the combination of RLE for drawing, and 1-bit mask work best;
it does tkae a bit more memory, but hey, not much.  (besides, how big
are your sprites gonna be?).

But I got a question now; how are people handling sprites larger than
32 pixels?  a long is only 32 pixels, so...  multiple banks?  Hmm.
bitshifting would be a pain...

Also, instead of checking each line, skipping lines also works, as long
as you don't have sprites 2 pixels tall..  (depending on how many lines
you skip.  (this wouldn't really save too much time, would it?  bit &'s
are fast.)

-Jimmy Dang, BlairHS Senior
 [e-mail]

--
Lam Dang
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 28 Dec 1995 19:00:49 GMT
Organization: Helsinki University of Technology

In article <4bsgk0$[e-mail]> Bernie Wieser <[e-mail]> writes:
>The basic form is this; you have a bitmap (not a pixmap) that you
>can convert to a region.  Then just call
>the toolbox on the regions for intersection.
>This means your sprite object has a region,
>but you can dispose of your bitmap once you've
>got the region.

Regions are not particularly fast for this kind of work. Inside
Macintosh has the incorrect statement that OffsetRegion is fast: it is
not as fast as they claim. I think the reason it says that might be
that the implementation used to be different, but was later changed
(before 1984).

--
Juri Munkki [e-mail]              Life is easy when polygons are cheap.
http://www.iki.fi/~jmunkki                 Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From Bernie Wieser <[e-mail]>
Date: 29 Dec 1995 19:24:09 GMT
Organization: Octavian Micro Development Inc.

I don't have a problem with it being slow...
because I only call it when sprite bounding
rects intersect, and in most situations where
I use it, there are never more than 4 collisions
possible.  It's not a problem.

B.




+++++++++++++++++++++++++++

>From [e-mail] (Emmanuel Rayzal)
Date: Fri, 29 Dec 1995 22:15:49 +0200
Organization: Internet-Way

Hi !

I'm the original poster of this thread. I've thinking a little bit and I
have now
a fast solution.

So, I use RLE for drawing, and RLE for collision detection (after checking that
boundrects intersects).

The source code is just here. (based on RLE as described in chapter 3 of
"Tricks of the Mac Game Programming Gurus")

The function Check Collision takes as parameters the 2 sprites, and the offset

The function GetNextRun search the next run of pixels for a sprite (line,
beginning
(left) and length). Returns false when no more pixels to draw.

I've a faster version with no function call for GetNextRun. I didn't
include it because it's really unreadable, just ask.


/********** CheckCollision *********/
// offset = pos2 - pos1

Boolean CheckCollision(tSpriteInfo *sprite1,tSpriteInfo *sprite2, Point offset)
{
    unsigned char *ptr1 = (unsigned char *)((*(sprite1->fSpriteData))
                                        + sizeof(Rect));
    unsigned char *ptr2 = (unsigned char *)((*(sprite2->fSpriteData))
                                        + sizeof(Rect));

    short line1,line2;  // current line number for both sprites

    short start1,start2,length1,length2,start1bis;

    line1 = line2 = start1 = start2 = 0;

    line1 += offset.v;

    // Get first run of each sprite

    if (GetNextRun(&ptr1,&line1,&start1,&length1) == 0)
        return false;
    if (GetNextRun(&ptr2,&line2,&start2,&length2) == 0)
        return false;

    while (1)
    {
        if (line1 == line2) // got a run on matching line
        {
            start1bis = start1 + offset.h;

            if (start1bis < start2) // 1 begins before 2
            {
                if (start2 < start1bis +length1)    // 2 begins before 1's end ?
                    return true;        // yes -> collision
                else if (GetNextRun(&ptr1,&line1,&start1,&length1) ==
0)    // no -> next r1
                    return false;
            }
            else if (start1bis > start2)
            {
                if (start1bis < start2 + length2)   // 1 begins before 2's end ?
                    return true;    // yes -> collision
                else if (GetNextRun(&ptr2,&line2,&start2,&length2) ==
0)    // no -> next r2
                    return false;
            }
            else // if (start1+offset.h == start2)
                return true;    // I assume there's no empty runs

        }
        else if (line1 > line2) // got a run on non matching lines
        {
            if (GetNextRun(&ptr2,&line2,&start2,&length2) == 0)
                return false;
        }
        else // if (line1 + offset.v < line2)
        {
            if (GetNextRun(&ptr1,&line1,&start1,&length1) == 0)
                return false;

        }
    }
    return false;       // end of (one) sprite - still no collision
}


/********** GetNextRun *********/
// call it first with *line = 0, *start = 0

Boolean GetNextRun(unsigned char **srcPtr,short *line,short *start,short
*length)
{
    unsigned long tokenOp;          // the op code from the token
    unsigned long tokenData;        // the data from the token

    while (true)
    {
        tokenOp = ( *( ( unsigned long * )(*srcPtr) ) ) >> 24;
        tokenData = ( *( ( unsigned long * )(*srcPtr) ) ) & 0x00ffffff;

        switch(tokenOp)
        {
            case kLineStartToken:   // new line
                    (*line) ++;         // increment line (Line Feed)
                    (*start) = 0;       // Carriage return :-)
                    (*srcPtr) += sizeof (unsigned long *);  // skip instruction
                    break;

            case kDrawPixelsToken:              // ok, we have the run
                    (*srcPtr) += (sizeof (unsigned long *)     // skip
instruction
                                    + tokenData     // skip data
                                    +  (( ( tokenData & 3L ) == 0 ) ? 0 :
( 4 - ( tokenData & 3L ) ))); // padding
                    (*length) = tokenData;
                    return true;
                    break;

            case kSkipPixelsToken:
                    (*start) += tokenData;              // increment start
                    (*srcPtr) += sizeof (unsigned long *);  // skip instruction
                    break;

            case kEndShapeToken:
                    return false;       // end of sprite, no run found
                    break;

            default:
                    // we should never get here
                    DebugStr("\pGetNextRun - unknown token");
        }
    }
}

- -
Emmanuel Rayzal

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Mon, 01 Jan 1996 00:21:04 -0800
Organization: ErsteSoft

In article <4buph1$[e-mail]>, [e-mail] (Juri Munkki) wrote:

> In article <4bsgk0$[e-mail]> Bernie Wieser <[e-mail]> writes:
> >The basic form is this; you have a bitmap (not a pixmap) that you
> >can convert to a region.  Then just call
> >the toolbox on the regions for intersection.
> >This means your sprite object has a region,
> >but you can dispose of your bitmap once you've
> >got the region.
>
> Regions are not particularly fast for this kind of work. Inside
> Macintosh has the incorrect statement that OffsetRegion is fast: it is
> not as fast as they claim. I think the reason it says that might be
> that the implementation used to be different, but was later changed
> (before 1984).

I think you're right about that.

Specifically, the reason they give for why it's supposed to be fast is
that "most of the data defining a region is stored relative to rgnBBox and
so isn't actually changed by OffsetRgn." That turns out to be untrue. In
fact, NOTHING in a region's data is based on rgnBBox (except for rgnBBox
itself, of course).

It could have been. It's a trifling change in (the interpretation of) the
data structure. So either the implementation changed after they told the
manual writers it was fast, or they planned to change it to make OffsetRgn
fast and never got around to it.

In any event, a Region is basically a RLE representation, so any RLE-base
algorithm should have similar run time. If you already have RLE sprites,
it shouldn't be hard to write your own collision detection routine that
runs directly off the RLE data, and still beats OffsetRgn+SectRgn handily,
because your routine won't have to do the OffsetRgn, AND it won't have to
actually produce a region representing the intersection.

-Ron Hunsinger

---------------------------

>From [e-mail] (Lam Dang)
Subject: char *pixel access; SwapMMUmode?
Date: Tue, 26 Dec 1995 04:23:04 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In all of the sample code I've seen, I see:

Byte mode=true32b;
SwapMMUMode(&mode);
// pixel access (of pixmap, screen (heaven forbid), whatever)
SwapMMUMode(&mode);

For my wonderful scroller engine, I've done the same; however, I'm curious;
why is this neccessary?  I'd experiment, but I don't have a mac right now.
(Chrismas vacation.. anyone wanna lend me a mac?)  I'd look it up, but I
don't have Inside mac.  :P.

Also, more random questions;
        -Which is faster, memcpy() or BlockMove()?  Equivalent?
        -Does MacTCP support nonblocking calls?  (Dynamic client connections)
        -Is it at all feasible to synchronize to the vertical retrace?
         (To get rid of shearing)
        -What is the maximum theoretical FPS for blitting large areas?
         (e.g. 256x256, 512x512, etc.. also non 2^n areas, like 304x304)
         (Need to have a goal to aim for)
        -How about drawing every other scanline?  (for direct screen access)
         (Yes, I KNOW direct screen is taboo, but rest assured, I plan to
          make it an option)
        -What are the disadvantages of not using an event loop?
         (i.e. using only MouseLoc, GetKeys, etc.)
        -There is a nonblocking event checker, right?
        -I'm CopyBits-ing direct to the screen; is this alright, or should
         I be using some weird type of window that covers the entire screen?

-Jimmy Dang, Blair HS Senior
 [e-mail]
 "This message is 100% Phat Phree."  (sorry hh).

PS Oh yeah, Merry <insert fav holiday here>.
--
Lam Dang
[e-mail]



+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Tue, 26 Dec 1995 23:16:06 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Lam Dang) writes:
> In all of the sample code I've seen, I see:
>
> Byte mode=true32b;
> SwapMMUMode(&mode);
> // pixel access (of pixmap, screen (heaven forbid), whatever)
> SwapMMUMode(&mode);
>
> For my wonderful scroller engine, I've done the same; however, I'm curious;
> why is this neccessary?

As I understand it, it's because the video memory may not be in a
space accessible with a 24-bit address. But please don't quote me,
because I'm not sure.

>   -Which is faster, memcpy() or BlockMove()?  Equivalent?

BlockMove will always be as fast as possible on whatever Mac it's
running on. (Except that you may want to call BlockMoveData instead,
if you're not copying executable code. The only difference is that
BlockMoveData doesn't clear the instruction cache.) memcpy may just
call BlockMove, but if it doesn't, it's probably slower.

>   -Does MacTCP support nonblocking calls?  (Dynamic client
connections)

Sorry, dunno.

>   -Is it at all feasible to synchronize to the vertical retrace?
>    (To get rid of shearing)

It's possible in simple cases, but it can get arbitrarily complicated.
I don't think most games bother, and I've never complained about
shearing problems, so... don't bother.

>   -What is the maximum theoretical FPS for blitting large areas?
>    (e.g. 256x256, 512x512, etc.. also non 2^n areas, like 304x304)
>    (Need to have a goal to aim for)

Depends heavily on the CPU and video hardware. Of course!

The goal to aim for is (of course) beating CopyBits. If you can't do
that, well, you know what conclusion to draw.

>   -How about drawing every other scanline?  (for direct screen access)
>    (Yes, I KNOW direct screen is taboo, but rest assured, I plan to
>     make it an option)

Twice the previous answer.

>   -What are the disadvantages of not using an event loop?
>    (i.e. using only MouseLoc, GetKeys, etc.)

Background apps don't execute. The menu bar clock doesn't update
(assuming your game leaves the menu bar visible.) Nobody complains
much about this during the game itself; people seem to be resigned to
the fact that they can't play Marathon during long FTP sessions. But,
of course, you should have a normal event loop for menu screens and
the game-pause screen.

Also, do you mean GetMouse? I can't find "MouseLoc"; if it's a
low-memory global, you should avoid it.

>   -There is a nonblocking event checker, right?

GetNextEvent. I'm told it's a little slower if there is no pending
event, so it helps to send yourself an event before calling
GetNextEvent. But I've never verified or tried this.

Last time I wrote a high-speed game, I used GetMouse and GetKeys and
ignored events entirely. But I had to flush key and mouse events
before returning to the menu event loop.

>   -I'm CopyBits-ing direct to the screen; is this alright, or should
>    I be using some weird type of window that covers the entire screen?

Oh, god, please use a window that covers the entire screen. (Nothing
weird about it; just pick the window style that has a one-pixel
border.) This doesn't cost any speed, it costs minimal memory
(NewWindow etc don't allocate very much at all), and everybody will be
happier if you don't mess with the root GrafPort.

Besides, then you can provide a running-in-a-regular-window mode for
people who want it. And it's easier to move to different monitors. And
you can get sensible mouse events in your menu event loop. And, in
fact, why the heck aren't you doing this already?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 27 Dec 1995 12:57:02 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>, Lam Dang <[e-mail]> wrote:
>In all of the sample code I've seen, I see:

>For my wonderful scroller engine, I've done the same; however, I'm curious;
>why is this neccessary?

This is because the pixel map data might be located inside a NuBus video
card instead of residing in main memory. Accessing memory on these cards
might require switching to 32 bit mode if the processor is in 24 bit mode,
because they have fixed, high addresses which are too large to fit into
a 24 bit pointer.

Be aware that SwapMMUMode is slow, that you need to always restore the
previous mode carefully, and that you can't make any System/Toolbox
calls while the mode is swapped.

You can avoid using SwapMMUMode in several cases:

 - if you know the Mac is currently in 32 bit mode, which is always
   true on Power Macs.

or

 - if the pixel map you are trying to access has been created by
   calling NewGWorld with the keepLocal flag set. This flag tells
   QuickDraw not to allocate memory inside a video card. It can be
   slower because some accelerated cards are designed to carry their
   own memory which they can access quickly, but at least it makes
   your life simpler.

I have applied these rules and stayed out of trouble until now,
so I think they're correct. Someone please correct me if I'm wrong.

>       -Which is faster, memcpy() or BlockMove()?  Equivalent?

On a particular machine, I don't know, but if you use BlockMove
you'll win because it's in ROM and it is optimized for the very
machine it is on, so it'll generally beat memcpy.

>       -I'm CopyBits-ing direct to the screen; is this alright, or should
>        I be using some weird type of window that covers the entire screen?

Hide the menu bar and use a window. This way, an update event
will be generated for other apps when you close the window.

Hope this helps,



--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Wed, 27 Dec 1995 16:15:15 -0800
Organization: Apple Computer, Inc.

Beware of calling BlockMove or BlockMoveData to copy from your own
offscreen buffer to the screen directly.  BlockMove/BlockMoveData is
optimized for source and destination to both be cacheable.  IO space is
noncacheable, so you will get an multiple access faults for each call.  Of
course the operating system will hide this from you, you just will have a
really really slow transfer rate.

If you are copying to/from uncacheable memory, use
BlockMoveUncached/BlockMoveDataUncached.  These calls, I believe, are
implemented in System 7.5.2 and later.

Cameron Esfahani

+++++++++++++++++++++++++++

>From Hiep Dam <[e-mail]>
Date: Sun, 31 Dec 1995 01:21:24 -0700
Organization: From The Witches' Brew

Lam Dang wrote:
>
> In all of the sample code I've seen, I see:
>
> Byte mode=true32b;
> SwapMMUMode(&mode);
> // pixel access (of pixmap, screen (heaven forbid), whatever)
> SwapMMUMode(&mode);
>
> For my wonderful scroller engine, I've done the same; however, I'm curious;
> why is this neccessary?  I'd experiment, but I don't have a mac right now.
> (Chrismas vacation.. anyone wanna lend me a mac?)  I'd look it up, but I
> don't have Inside mac.  :P.
>

>From my understanding (which may or may not be 100% correct ^_^):
You need to use SwapMMUMode in the case that your computer is running
under 24-bit addressing mode [heaven forbid!]. Due to the way video
memory may be located on VRAM or a video card, access here is always
32-bit. So you have to switch to 32-bit addressing in order to access
video memory. Trying to access vram while under 24-bit addressing
might give you bogus values.

My opinion is don't bother with it. I've written plenty of blitters
which pretty much omit this - they assume they're running under 32-bit
addressing. It's pretty rare these days to find a Mac that's NOT
running under 32-bit addressing. As an added bonus, IT'S MUCH
FASTER!!! Yes, I checked. I ran my blitters under 24-bit addressing
mode (where they had to use SwapMMUMode) and under 32-bit addressing.
The difference was significant, around 10%-30% faster under 32-bit
addressing. Sorry I can't remember the exact figures... Probably due
to less overhead in calling the 2 SwapMMUMode calls...

However, just to be on the safe side if you do decide to do it this
way, best to check at launch whether 24 or 32-bit addressing is set
and warn your user you can run under 32-bit addressing only. [Funny...
I wrote a small set of routines which does this exactly, and then some
- called Witch Doctor. Look to my web site below if you want to check
it out. Look in the Sourcery section. Sorry about the personal plug! I
couldn't resist... ^_^]

--
->Hiep Dam
->http://members.aol.com/starlabs/hiep_page.html
--
->my contribution to the English language:
"netsexual" (net-sek'shoo-el) n. for some bizarre reason, almost
always, a man posing as a woman on the internet.

+++++++++++++++++++++++++++

>From [e-mail] (Matthew)
Date: Mon, 01 Jan 1996 18:30:11 -0500
Organization: PANIX Public Access Internet and Unix, NYC

10-30% seems a little high to me... unless you are using SwapMMUmode
before and after drawing each sprite seperately instead of as a group.  As
long as you dont use any system calls in the loop that updates all the
sprites to the screen there shouldnt be any problems.

i.e.

slow:
- ---
for sprite=0 to num_of_sprites
  SwapMMUmode
  drawsprite_to_screen (sprite)
  SwapMMUmode
next

fast:
- ---
SwapMMUmode
for sprite=0 to num_of_sprites
  drawsprite_to_screen (sprite)
next
SwapMMUmode

of course for ppc apps you can leave out the SwapMMUmode

Matthew

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 2 Jan 1996 10:25:15 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Matthew <[e-mail]> wrote:
>slow:
>-----

>fast:
>-----

Sure, SwapMMUMode is very slow, so it's important to call it
as little as possible.

>of course for ppc apps you can leave out the SwapMMUmode

As far as I remember, when compiling for PowerPC SwapMMUMode is
a macro which compiles to nothing, so you can leave it in and there
is no overheard.

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

---------------------------

End of C.S.M.P. Digest
**********************